Handling the Undo and Redo menu items (Parts don't have to do this. This information is for container application writers.)
Container applications should manage the Undo and Redo menu items and should call Undo and Redo when they are selected. Here's some sample code for the display and activation of these menu items:
ODUndo* undo = MyGetSession()->GetUndo(ev);
ODPart* part;
ODActionData actionData;
ODActionType actionType;
ODName* actionLabel;
// CREATE EMPTY ITEXT STRUCTURE TO BE COPIED INTO
actionLabel = CreateIText(UCHAR_MAX);
// LOOK AT THE STACK
if (undo->PeekUndoHistory(ev, &part, &actionData, &actionType,
(ResetUndoText is a function that sets the text of the Undo menu item to the default string.)
Nesting transactions
Multi-stage Undo can be nested, that is, it is not an error if another begin action is placed in the action history before the current transaction is finished. Of course there must be a corresponding end action for end begin action and the nested transaction must be completed nested inside the outer transaction (no overlapping). When calling AbortCurrentTransaction, any actions associated with nested transactions as well as those associated with the current transaction are also cleared.
AbortCurrentTransaction
When AbortCurrentTransaction is called, the actions which are cleared trigger calls to the DisposeActionState methosd of the parts associated with the actions. Before this happens, the parts should also be asked to undo the actions via a call to the parts' UndoAction method. In OpenDoc 1.0.4, this does not occur. This bug will be fixed in a future release of OpenDoc.
Order of action disposal
Parts should not count on the order in which DisposeActionState will be called for actions that they have placed in the action history.